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FIELD OF THE INVENTION 

The present invention generally relates to Internet Protocol (D?) 
networks, and more specifically, to establishing end-to-end. QuaUty of Service (QoS) 
in IP networks with multimedia applications. 

5 BACKGROUND 

IP networks were originally designed to carry "best effort" traffic 
where the network makes a "best attempt" to deliver a user packet, but does not 
jI guarantee that a user packet will arrive at the destination. Because of the market 

lis 
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success of IP networks, there is a clear requirement for mechanisms that allow IP 
networks to support various types of applications. Some of these applications have 
in Quality of Service (QoS) requirements other than "best effort" service. Examples of 
113 such applications include various real time applications (IP Telephony, video 
Q conferencing), streaming services (audio or video), or high quality data services 
p (browsing with boimded download delays). Recognizing these QoS requirements, 
^li the Internet Engineering Task Force (IETF), which is the main standards body for IP 
networking, standardized a set of protocols and mechanisms that enable IP network 
operators to build QoS-enabled IP networks. 

Fig. 1 depicts a simplified high-level model of an IP network which 
may be useful in explaining QoS provisioning. As can be appreciated, the model 

20 includes two users, but could easily be expanded to include more users without 
changing the basic functionality of the network. In Fig. 1, User-A 101 may 
communicate with User-B 102 or with an appHcation server 103. For example, in 
the case of an IP telephony session, User-A 101 may communicate with User-B 102. 
Similarly, in the case of streaming services, User-A 101 may commimicate with the 

25 appHcation server 103, which may be configured as a video server. In either case. 
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User-A 101 accesses an IP backbone network 104 through a local access network 105, 
such as PSTN (dial-in access), Global System for Mobile Communications (GSM), or 
Universal Mobile Telecommunications System (UMTS) network. User-B 102 is 
similarly connected to the IP network 104 through a local access network 106. It 
5 will be appreciated that User-A and User-B need not use the same type of access 
network. The IP network 104 may consist of a number of IP routers and 
interconnecting links that together provide connectivity between the IP network's 
ingress and egress points and thereby make two party communication possible. As 
far as the users are concerned, the perceived QoS depends on the mechanisms both in 

IS) the access networks 105, 106 and on the IP backbone network 104. Of particular 

Q 

CIO interest to this invention is the specific case where at least one of the access networks 

■"^ 

,0 is a UMTS or GSM/GPRS network. 

3 

When users access IP-based services, they may use a device that nms an 
P, application program that provides the interface for the user to access the particular 

service. For instance, in Fig. 1, User-A may use a laptop running a conferencing 
13 application program to attend an IP network based meeting, where participants of 

the meeting collaborate using various programs. Such programs are well known in 

the art. 

Various user appHcations may access network services through an 
20 appHcation programming interface (API). An API provides application 

programmers with a uniform interface to access underlying system resources. For 
instance, an API may be used to configure a network resource manager to require 
that a particular IP packet originating from a given application receive a certain 
treatment from the network, such as a particular QoS. For example, if the IP 
25 network is a Differentiated Services IP network, then an application program may 
request that all of its IP packets receive the "Expedited Forwarding" treatment. 
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The User (and the API in the user's equipment) may not be aware of 
the different technologies that various access networks and IP backbone networks 
employ in order to provide QoS end-to-end, i.e., from User-A all the way to remote 
User-B. For instance, the application program may use an RSVP/IntServ based API, 
5 and the end-to-end embodiment in which he is involved may include a UMTS access 
network and a non-RSVP enabled IP network. In such cases, some "interworking" 
mechanisms between such different technologies and protocols are needed to make 
sure that the QoS is provided end-to-end. 

Integrated Services (IntServ) provides a set of well-defined services 

fl2) which enables an application to choose among multiple, controlled levels of delivery 
IS . . 

--'4 service for its data packets. To support this capability, two things are required. 

NS 

ya First, individual network elements, such as subnets and IP routers, along the path 
followed by an application's data packets must support mechanisms to control the 

I'I'I quality of service deUvered to those packets. Second, a way to communicate the 
application's requirements to network elements along the path and to convey QoS 

5|3 management information between network elements and the application must be 

I'U 

provided. 

IntServ defines a number of services such as Controlled-Load (defined 
in IETF RFC 2211) and Guaranteed (defined in IETF RFC 2212). The service 
20 definition sets forth the required characteristics of the network equipment in order 
to deliver the service. The individual network elements (subnets and IP routers) that 
support the service must comply with the definitions defined for the service. 

The service definition also defines the information that must be 
provided across the network in order to establish the service. This function may be 
25 provided in a number of ways, but it is frequently implemented by the resource 
reservation setup protocol RSVP (defined in IETF RFC 2205). RSVP (Resource 
reSerVation Protocol) is an IP-level resource reservation setup protocol designed for 
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an IntServ-enabled Internet (defined in IETF RFC 1633, 2205, and 2210). The RSVP 
protocol is used by a local host (e.g., User A's computer) to request a specific quality 
of service from the network for particular application data streams or flows along the 
data path between sender and receiver. RSVP is also used by routers to deliver 
quality-of-service requests to all nodes along the path(s) of the flows and to establish 
and maintain the state(s) to provide the requested service. RSVP requests generally 
result in resources being reserved in each node along the data path. 

Fig. 2 shows an End-to-End Integrated Service between the hosts. The 
service is provided using routers and hosts that support the service definition defined 
for the required service and through signaling of the relevant information between 
the nodes. In order to use RSVP, each of the devices in the path between the sender 
^1 and receiver must be capable of understanding and sending RSVP messages. 
liH However, some end devices may not be RSVP-enabled, and therefore, can not use 
13 RSVP to reserve bandwidth or other quality of service characteristics. An RSVP 

"proxy" can be defined to solve this problem by emulating an RSVP sender or 
iIj receiver on behalf of such devices. More generally, a proxy is a network device, such 
as a router or a switch, that performs one or more functions on behalf of another 
device. As apphed to RSVP, an RSVP Proxy originates the RSVP PATH message 
and receives the incoming RESV message on behalf of a non-RSVP enabled node. 
20 (PATH and RESV are examples of RSVP messages.) It also receives an incoming 
PATH message and originates the RESV response message on behalf of a non-RSVP 
enabled node. In other words, the RSVP Proxy acts on behalf of the non-RSVP 
enabled node to facilitate resource reservation without that node having to be 
involved in the RSVP signaling. 

25 The problem addressed here is how to estabHsh a protocol proxy 

relationship in a multimedia session involving a mobile communications access 
network and a non-enabled mobile terminal. A mechanism is provided that allows 
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the non-enabled mobile terminal to commimicate a protocol proxy request with an 
enabled node along the send-receive path between the mobile terminal and a remote 
host. A mechanism is further provided to install information in the enabled node so 
that the node can function as the protocol proxy for the non-enabled mobile host. 

5 In setting up a multimedia session between the mobile terminal and the 

remote host by way of an access point coupled to a packet data network, the mobile 
terminal sends a request message associated with the multimedia session to the access 
point. The message requests a packet access bearer between the mobile terminal and 
liei the access point. The mobile terminal sets an indicator in the request message to 
0 indicate that the access point should function as a communications protocol proxy 

\l for the mobile terminal for the multimedia session. 

^0 

111 
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From the perspective of the access point, the received request message is 
asking for a packet access bearer between the mobile terminal and the access point 
for the multimedia session. Detecting the indicator in the request message means 

113 

Ift that the access point should function as a communications protocol proxy for the 
13 . . 

fy mobile terminal for the multimedia session. Accordingly, the access point performs 
as the communications protocol proxy for the mobile terminal for the multimedia 
session. 

In one non-limiting example, the request message indicates a particular 
20 Quality of Service (QoS), and the communications protocol is the resource 
reservation protocol (RSVP). Thus, the access point is an RSVP proxy for the 
mobile terminal during the multimedia session. The mobile terminal may be a User 
Equipment (UE) that communicates with a General Packet Radio Service (GPRS) 
access network by way of a UMTS Terrestrial Radio Access Network (UTRAN). In 
25 this context, the access point may be a Gateway GPRS Service Node (GGSN). The 
request message may be a Packet Data Protocol (PDP) context request message, and 
the indicator may be an RSVP proxy flag. In one example implementation, the PDP 
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context request message may include the RSVP proxy flag as a PDP configuration 
option (PCO). "When the indicator is set, an RSVP proxy state process for the 
multimedia session is installed from a multimedia server in the GGSN. Thereafter, 
the RSVP proxy-GGSN generates an RSVP PATH message directed to the remote 
5 host, and in response thereto, receives an RSVP RESV message from the remote host 
on behalf of the mobile terminal. It also generates an RSVP RESV message in 
response to a received RSVP PATH message as well as generates/ responds to RSVP 
messages other than PATH and RESV, e.g., RESVcont. 

U Another aspect of the invention includes a computer-generated data 

13 

fg) signal embodied in an electrical signal for use in a GPRS/UMTS network. A Packet 

\^ Data Protocol (PDP) context activation, creation, modification, or update message 

^1 for establishing or updating a multimedia session between a mobile terminal and a 

Jl^ remote host includes plural fields of information. In particular, the PDP message 

j3 includes a PDP configuration options (PCO) field that includes an indicator 

% indicating whether the access point should function as a communications protocol 

13 proxy for the mobile terminal for the multimedia session. In one example 

ru 

implementation, the indicator field is included with an authorization token and a 
media binding token associated with the multimedia session. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, features, and advantages of the present 

invention may be more readily understood with reference to the following 
description taken in conjunction with the accompanying drawings. 

Fig. 1 is a block diagram of a high level IP network; 

Fig. 2 is a block diagram depicting an example of a network employing 
end-to-end integrated services; 
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Fig. 3 illustrates a communications system in which a multimedia 
session may be established between a mobile terminal and a remote host; 

Fig. 4 illustrates in block format various functions performed by the 
mobile terminal, access point, and multimedia system; 

Fig. 5 is a flowchart illustrating example procedures for establishing a 
protocol proxy for a multimedia session in the system shown in Fig. 3; 

Fig. 6 illustrates a GPRS/UMTS-based communication system for 
conducting multimedia sessions in which the present invention may be employed; 



J'O Fig. 7 is a block diagram illustrating a PDF context in the system 

%So shown in Fig. 6; 

5 

13 
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Fig. 8 illustrates a portion of a PDP context request message carrying an 
RSVP proxy flag; 



Fig. 9 is a flowchart illustrating example procedures for establishing a 



multimedia session in the system shown in Fig. 6 where the present invention is 



15 used; and 

Fig. 10 is an example signaling diagram of multimedia session message 
exchanges related to the procedures shown in Fig. 9. 



DETAILED DESCRIPTION 

In the following description, for purposes of explanation and not 
20 limitation, specific details are set forth, such as particular embodiments, procedures, 
techniques, etc. in order to provide a thorough understanding of the present 
invention. However, it will be apparent to one skilled in the art that the present 
invention may be practiced in other embodiments that depart from these specific 
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details. For example, while the present invention is described in an example 
application to the GSM/UMTS system, the present invention may be employed in 
any access network system. 

In some instances, detailed descriptions of well-known methods, 
5 interfaces, devices, and signaling techniques are omitted so as not to obscure the 
description of the present invention with unnecessary detail. Moreover, individual 
function blocks are shown in some of the figures. Those skilled in the art will 
appreciate that the functions may be implemented using individual hardware circuits, 

H using software functioning in conjunction with a suitably programmed digital 

112 

fSo microprocessor or general purpose computer, using an application specific integrated 

CO 

"4 circuit (ASIC), and/or using one or more digital signal processors pSPs). 

\a 

i| In the following description, a mobile terminal is used as one example 



of a user equipment (UE) allowing a user access to network services. In a mobile 
radio communications system, the interface between the user equipment and the 



13 

i,y 
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Ifls network is the radio interface. Thus, although the present invention is described 

13 

lU using the term "mobile terminal," the present invention may be appHed to any type 
or configuration of user equipment that can commimicate over a radio interface. 

To realize a QoS with clearly defined characteristics and functionahty, 
a bearer must be set up from the source to the destination of the service that supports 

20 that QoS. A bearer is a logical connection between two entities through one or 

more interfaces, networks, gateways, etc., and usually corresponds to a data stream. 
A QoS bearer service includes all aspects to enable the provision of a contracted 
QoS. These aspects are among others the control signaling, user plane transport, and 
QoS management fimctionality. To provide IP quality of service end-to-end from 

25 mobile terminal to a remote host, it is necessary to manage the quality of service 
within each domain in the end-to-end path where each domain corresponds to a set 
of nodes utilizing the same QoS mechanisms. 
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As explained in the background, it may be the case that not every node 
in the end-to-end path supports a particular protocol being used to set up, reserve, or 
otherwise support a QoS related to a mukimedia session. In a multimedia 
communication between a mobile terminal and remote host, it may be that the 
mobile terminal does not support a QoS reservation protocol supported by the 
remote host and the nodes in the end-to-end path between the mobile terminal and 
the remote host. In this case, the mobile terminal may request one of the nodes in 
the path to function as its protocol proxy to send and receive protocol messages on 
its behalf. 

Consider the example, simplified communications system shown in 
Fig. 3 which permits a Mobile Terminal (Ml) 10 to initiate and conduct a 
multimedia session with a remote host 20. In this example, the MT 10 is a non- 
enabled protocol host. The remote host 20 can be a fixed or wireless device, and in 
this example, is an enabled protocol host. The mobile terminal 10 is coupled to a 
radio access network (RAN) 12 over the radio interface. The RAN 12 is coupled to 
an Access Point 15 in a packet-switched access network (PSAN) 14. The access point 
15 functions as the protocol proxy for the MT local host. Protocol messages to be 
sent and received by the MT 10 are sent and received by the access point 15 on behalf 
of the MT 10. The PSAN 14 is coupled to a Packet Data Network (PDN) 18 to 
which the remote host 20 is coupled. The basic traffic flow for a multimedia session 
(shown as sohd lines) between the mobile terminal 10 and remote host 20 is 
transported via these three networks 12, 14, and 18. The PSAN 14 and the PDN 18 
communicate multimedia control signaling (shown as dashed lines) to a Multimedia 
System 16 that can be separate from or an integral part of the Packet Data 
Network 18. 

To provide further details regarding setting up a muhimedia session 
between the MT 10 and the remote host 20, reference is now made to Fig. 4. The 
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mobile terminal 10 includes Access Network Bearer Control 40 coupled to 
multimedia session control 42, The Access Network Bearer Control block 40 
transports internal bearer control signaling, which is not dedicated to a particular 
session, to an Access Network Bearer Control block 46 in the Access Point 15 
5 transparently through the radio access network over a PDN signaling transport 
bearer. Both Access Network Bearer Control blocks 40 and 46 assist in establishing 
a packet access bearer for setting up the session shown as the pipe entitled "transport 
of session signaling," Over this bearer, the mobile terminal 10 initiates a multimedia 
session including a plurality of media data streams with the remote terminal 20. 
C'JIo Each media data stream or "flow" is transported over a corresponding packet access 
i;g bearer illustrated as a "transport of media flow" pipe coupled to a Forward Media 
yp Streams block 44 in the mobile terminal. Two media flows 1 and 2 are shown for 
ll purposes of illustration in this multimedia session. The multimedia system 16 in the 
Ji^ packet data network 18 employs a Route Media Streams block 50 to route the 
J|^5 packets in each media flow between the mobile terminal 10 and the remote 
l| terminal/host 20. Multimedia system 16 includes a Session Control and Policy 
f5 Control block 48 that utilizes session signaling from the Multimedia Session Control 
block 42 in the mobile terminal 10 to correlate each multimedia flow and its 
corresponding quality of service requirements with the session to establish necessary 
20 admission and policy enforcement rules for the session. Those rules are provided 
upon request to the Access Network Bearer Control block 46 which performs 
admission and policy enforcement operations for the session in accordance with the 
obtained session rules. 

The protocol proxy relationship between the MT 10 and the access 
25 point 15, where the access point 15 is the proxy for the MT 10, is established during 
set up of each packet access bearer associated with the session. Example protocol 
proxy establishment procedures are described now in conjunction with the 
"Protocol Proxy" routine (block 60) show in the flowchart of Fig, 5, The mobile 
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terminal 10 sends a request message to the access point 15 requesting a packet access 
bearer between the mobile terminal and the access point (block 61). The mobile 
terminal 10 sets an indicator in the request message to request that the access point 
function as a commxmications protocol proxy for the mobile terminal (block 62). 
5 The access point receives the request message and detects the indicator (block 63). 
The access point then obtains from the multimedia system information needed to 
function as such a proxy for one or more identified media streams in the session, e.g., 
from the session control and poHcy control 46 (block 64). Once the proxy 
information is installed, the access point functions as a communications protocol 
IIP proxy for those media streams for the mobile terminal during the multimedia session 
ll (block 65). In particular, the access point generates/sends appropriate 
y0 communications protocol messages and processes received communications protocol 
['I messages on behalf of the mobile terminal for those media streams. 



m 



Thus, even though the mobile terminal cannot directly support 
communications protocol messaging with the remote host, the mobile terminal can 



13 do so indirectly through the proxy. The proxy indicator, being included in the 



packet access bearer request message, is an easy and effective way to inform the access 
point of the mobile terminal's need for a communications protocol proxy. The 
proxy indicator is advantageously sent at the same time that various attributes of the 
packet access bearer are being established and configured in the access point. As 
these bearer attributes are being configured, the communications protocol proxy is 
installed in the access point. 

Referring to Fig, 6, another non-limiting, example application of the 
invention will now be described in the context of a multimedia session set up via a 
General Packet Radio Service (GPRS)/Universal Mobile Telecommunication System 
(UMTS)-based access network 80. The packet access bearer service provided over a 
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GPRS/UMTS network 80 must deliver the required end-to-end bearer service 
including supporting a quality of service requested for that bearer. 

The GPRS/UMTS network 80 includes a set of network elements 
between the local host, corresponding to the Mobile Terminal (MT) 88, and an 
external packet switching network the user is connecting to like the Internet. The 
radio access network (RAN) 90 provides access over the radio interface to/from the 
MT and includes radio base stations and radio network controllers. The RAN 90 is 
coupled to a GPRS packet access network 92 that includes a supporting Gateway 
GPRS Support Node (SGSN) 94 and a Gateway GPRS Support Node (GGSN) 96. 
The GGSN 96 provides interworking between the GPRS/UMTS network and the 
IP backbone network 84. The coupling (shown as a soHd line) between the 
GPRS/UMTS network 80 and the IP backbone network 84 is used to transport user 
data IP packets. 

The GPRS/UMTS-type network 80 is coupled to an IP multimedia 
subsystem (IMSS) 82. Commimication with the IMSS 82 (shown as dashed Hnes) 
permits exchange of multimedia session control related messages. The IMSS 82 is 
typically a part of (although it may be separate from and coupled to) an IP backbone 
network 84. The remote host corresponding to user equipment (UE-B) 102 is 
coupled to the IP backbone network 84 through its home cellular network 86, and 
by signaling connection, to the IMSS 82. 

The mobile terminal 88 corresponding to UE-A 88 desires to establish a 
multimedia session with UE-B 102. The packet traffic for this session follows the 
solid line couplings between the various nodes. The session is established and 
managed using Session Initiation Protocol (SIP), and therefore, the user 
equipments 88 and 102 correspond to SIP User Agents (SIP UA). The IP multimedia 
system 82 includes a Call State Control Function (CSCF) 98, and a Policy Control 
Function (PCF) 100. CSCF 98 and PCF 100 may be implemented on the same or 
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different servers. The Call State Control Function 98 functions as a SIP proxy for 
the SIP user agent UE-A 88. 

Before the mobile terminal can send packet data to the remote host, the 
mobile terminal must "attach" to the GPRS network to make its presence known 
5 and to create a packet data protocol (PDP) context to establish a relationship with a 
GGSN. The PDP attach procedure is carried out between the mobile terminal and 
the SGSN to establish a logical link. As a result, a temporary logical link identity is 
assigned to the mobile terminal. A PDP context is established between the mobile 
terminal and a GGSN selected based on the name of the external network to be 
it© reached. One or more application flows (sometimes called "routing contexts") may 
ijp be established over a single PDP context through negotiations with the GGSN. An 
^ application flow corresponds to a stream of data packets distinguishable as being 

associated with a particular host appHcation. An example application flow is in an 
'-^> electronic mail message from the mobile host to a fixed terminal. Another example 
G application flow is a link to a particular Internet Service Provider (ISP) to download 
13 a graphics file from a website. Both of these application flows are associated with the 

in 

Q same mobile host and the same PDP context. User data is transferred transparently 

ry 

between the MS and the external data networks with a method known as 
encapsulation and tunneling. 

20 As explained earlier, QoS is a means for providing end users with 

satisfying service. It also enables efficient use of the radio resources. QoS can be 
characterized by several performance criteria such as throughput, connection setup 
time, percentage of successful transmissions, speed of fault detection and correction, 
etc. In an IP network, QoS can be measured in terms of bandwidth, packet loss, 

25 delay, and jitter. For a multimedia session between the mobile terminal and the 
remote host, the QoS must be end-to-end and must have the support of all nodes in 
the end-to-end path. 
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One way of ensuring such end-to-end QoS is to use the Resource 
Reservation Protocol (RSVP) which specifies resource reservation techniques for IP 
networks. RSVP is a protocol that enables resources to be reserved for a session 
prior to any attempt to exchange media between the MT and the remote host. 
5 There are other resource reservation/ assurance techniques and protocols, and the 
present invention can be used with these as well. However, for purposes of 
explanation, the following example embodiment is described in the context of RSVP. 

In RSVP, a sender first issues a PATH message to the remote receiver 
l|* via a number of routers. The PATH message contains a traffic specification (Tspec) 

fi) that provides details about the data that the sender expects to send in terms of 

IB 

^'4 bandwidth requirement and packet size. Each RSVP-enabled router along the way 

y3 

establishes a path state that includes the previous source address of the PATH 
!!'^ message (i.e., the next hop back towards the sender). The receiver of the PATH 
J'j message responds with a Reservation Request (RESV) that includes a flowspec. The 
Jl| flowspec includes a Tspec and information about the type of reservation service 
0 requested. These are the primary RSVP messages handled by the RSVP proxy, but 

the proxy preferably handles any other RSVP messages, e.g., RSVP RESVcont, as 

well. 

A problem with the multimedia session being established between the 
20 mobile terminal 88 and the remote host 102 in Fig. 6 is that the mobile terminal 88 is 
a non-enabled RSVP host. However, the rest of the IP routers in the path to the 
RSVP-enabled remote host 102 support RSVP. Thus, in order to use RSVP to 
reserve resources end-to-end for this session, the mobile terminal 88 needs an RSVP 
proxy. In this case, the GGSN 96 is chosen to perform that proxy role. The next 
25 step is to let the GGSN 96 know that the mobile terminal 88 needs the GGSN to be 
the mobile's RSVP proxy for this session. This information is communicated to the 
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GGSN 96 when one or more Packet Data Protocol (PDP) contexts is being 
established for the session. 

"Within a GPRS/UMTS access network, radio network resources are 
managed on a per PDP context level, which corresponds to one or more user 
5 flow/data streams and a certain QoS class. A PDP context is implemented as a 
dynamic table of data entries, comprising all needed information for transferring 
PDP data units between the mobile terminal and the GGSN, e.g., addressing 
information, flow control variables, QoS profile, charging information, etc. The 
relationship between a packet access bearer and a PDP context is a one-to-one 
ji^ mapping. The PDP context signaling carries the requested and negotiated QoS 
S;3 profile between the nodes in the UMTS network. It has a central role for QoS 
''iS handling in terms of admission control, negotiation, and modifying of bearers on a 
W QoS level. 

a 

l,y A PDP context is shown in Fig. 7. Briefly, the MT sends a PDP 

III message, e.g., "Activate PDP context request," to the SGSN which includes a 
Jy requested QoS profile. The SGSN sends "RAB Assignment Request" to the RNC in 
the RAN to establish a radio access bearer (RAB) service to carry the RAB QoS 
attributes. From the RAB QoS attributes, the RNC determines the radio-related 
parameters corresponding to the QoS profile, e.g., transport format set, transport 
20 format combination set, etc. The RNC sends a "Radio Bearer Set-up" message to the 
MT. The RAN and the MT are ready to transfer traffic, and a "RAB Assignment 
Complete" message is sent to the SGSN. 

The SGSN sends a "Create PDP Context Request" to the GGSN 
carrying the QoS profile. Based on this profile, an admission control is performed at 
25 the GGSN level, and the GGSN may restrict the QoS if, for example, the system is 
overloaded. The GGSN stores the PDP context in a database. The GGSN returns 
the negotiated QoS to the SGSN in a "Create PDP Context Response" message and 
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the SGSN stores the PDP context in its database. The negotiated QoS is sent from 
the SGSN to the MS in an "Activate PDP Context Accept" message. If either the 
SGSN or the GGSN has modified the QoS profile, then the MS has to either accept 
or reject this profile. 

5 The mobile terminal 88 can indicate to the GGSN 96 its need for an 

RSVP proxy in PDP context request either in activating/ creating a new PDP context 

or modifying/updating an existing one. A single bit field can be included in the PDP 

context request called the RSVP proxy flag or indicator. If the flag is set, the MT 

M requests the GGSN to be its RSVP proxy. If the flag is not set, the GGSN need not 
CI3 

© be its RSVP proxy. In one non-Hmiting example, the RSVP proxy flag field may be 
incorporated as a PDP Configuration Options (PCO) parameter in the PDP context 
J request message. Preferably, (although not necessarily), the RSVP proxy flag field is 
j!^ included as a PCO along with one or more "tokens" associated with the session. 
[ j Fig. 8 shows a partial PCO in a partial PDP comext request message. The PCO 
ji| includes three example tokens: a session identifier (ID), which can be used as an 
l3 authorization token, a media binding indicator (MBI), which is a token that 

identifies a media flow within the session, and the RSVP proxy flag field/token. 
Further information regarding session IDs, MBIs, and other session-related tokens 
may be found in several of the commonly-assigned, related applications listed above, 
20 the disclosures of which are incorporated herein by reference. 

Reference is now made to the Multimedia Session routine (block 1 10) 
in Fig. 9 which outlines in flowchart form example procedures for establishing a 
multimedia session between the MT (UE-A) and the remote host (UE-B). In 
particular, the MT (UE-A) requests that the GGSN function as its RSVP proxy using 
25 the PDP context request message format show in Fig. 9. A session signaling GPRS 
bearer is established between UE-A and the GPRS network 92 using well-established 
GPRS PDP context activation messages. This session signaling GPRS bearer 
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corresponds to a first or primary PDP context (block 112). XJE-A requests a 
multimedia session with the SIP UA remote UE-B over the session signahng GPRS 
bearer via the RAN 90, the GPRS network 92, the IP multimedia subsystem 82, the 
IP backbone network 84, and UE-B's home cellular network 86 (block 114). This 
5 request may be in the form of an SIP/SDP message sequence which contains 

sufficient information about the session, such as the source (UE-A) and destination 
(UE-B) end points, bandwidth requirements, and the characteristics of the media 
exchange, etc. to trigger an authorization of QoS resources procedure in the Call 
State Control Function 98. 

Q 

tt'i> The Policy Control Function 100 authorizes, if appropriate, the 

CiQ . . . 

required quality of service resources for the session and installs an IP bearer level 

policy for the session and each media flow based on the information from the Call 
J;^ State Control Function 98. In addition, the Policy Control Function 100 generates 
[ j an authorization "token" for the session corresponding to a session identifier. When 
U the multimedia session is authorized and the policy control function 100 stores 
C3 session information for each of the media flows in the session, the mobile terminal 

generates media binding information (MBI) for each media data stream in the session. 

The mobile terminal determines that the GGSN should function as its RSVP proxy 

for selected media data streams in the session (block 116). 

20 The mobile terminal requests a PDP context for each media stream and 

includes the session id, the MBI, and the RSVP proxy indicator to the GGSN in the 
PDP context request message as a PCO. The MBI is used to retrieve session, media, 
and policy related information from the multimedia system. Because the RSVP 
proxy flag is set, information needed for the GGSN to function as the RSVP proxy is 

25 also retrieved from the multimedia system (block 118). The session, media, and 
policy related information is used to decide if the PDP context is allowed to be 
established (admission control). The retrieved proxy information configures the 
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GGSN as an RSVP proxy, e.g., generating RSVP PATH messages and receiving 
RSVP RESV messages on behalf of the mobile terminal for the session (block 120). 

An example signaling flow diagram for the example multimedia session 
between the mobile terminal local host UE-A and remote host UE-B is shown in 
Fig. 10 and now described. Initially, UE-A establishes a first PDF context with the 
GGSN to establish a GPRS bearer for session signaling needed to establish the 
multimedia session. The UE-A then registers with the CSCF before sending a SIP 
INVITE message on the GPRS signaling bearer to the CSCF to setup the IP 
multimedia session. The INVITE message includes the session details regarding the 
number of media flows and requested corresponding quality of service. The CSCF 
authenticates the UE-A as a subscriber and authorizes the session. The SIP INVITE 
message is forwarded to UE-B via external networks. UE-B confirms the session 
request in a SIP "183" message returned to the CSCF. The SIP 183 is an 
acknowledgement message to the SIP INVITE message. 

The CSCF requests from the PCF a session identifier (ID) for the 
session and communicates session-related and media-related data to the PCF. The 
session ID corresponds to an authentication token. The PCF registers the session- 
related data and the media-related data, makes policy decisions for the session, issues 
the session ID (authorization token), and returns it to the CSCF. The CSCF 
confirms the session, and delivers the session ID in a SIP 183 message to the UE-A. 

The UE-A determines media information from each media stream, and 
generates media binding information (MBI) for each media stream using the session 
ID and the media information. Alternatively, the UE-A may receive the MBI from 
the CSCF in the SIP 183 message or from another entity. Still further, the UE-A 
may create the MBI using some other procedure that does not employ the session ID. 
In addition, the UE-A determines its need for an RSVP proxy. The UE-A activates a 
second PDP context (i.e., by sending a secondary PDP context request message to 
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the SGSN) for each media stream and includes in the PCO the session id, the MBI, 
and sets the RSVP proxy flag. 

The GGSN checks the PCO and detects the session id, the MBI, and 
the RSVP proxy flag. The GGSN uses the MBI as an identifier for each media 
5 stream and requests the pohcy/rules for the session and media stream in a Common 
Open PoUcy Service Protocol (COPS) REQ message. RSVP proxy information is 
also requested. In response, the PCF retrieves the session information and policy 
. decisions associated with the MBI for each media stream and returns the policy rules 

Q and other session-related and media-related information to the GGSN in a COPS 

13 

IB DEC message. The PCF also provides RSVP proxy information to be installed in 

■'4 

5,0 the GGSN. Using the obtained rules and information, the GGSN enforces the 

\Q 

m poHcy and installs the RSVP proxy information. It acknowledges the request for 

12 each secondary PDP context. The GGSN responds with a COPS RPT message. 

p 

j5 Thereafter, the GGSN is enabled as an RSVP proxy for the UE-A, 

M generating and terminating RSVP signaling for each media stream to/from UE-B. As 
an RSVP proxy, the GGSN generates an RSVP PATH message for each media data 
stream to UE-B, which is then confirmed by an RSVP RESV message from the 
UE-B. This is done for the establishment of the RSVP flow from the GGSN to the 
UE-B. The GGSN RSVP proxy responds to each RSVP PATH message from UE-B 
20 with an RSVP RESV message. This is done to establish the RSVP flow from the UE- 
B to the GGSN. Two RSVP flows are established for each bidirectional media data 
stream for which GGSN has established the RSVP proxy function. 

While the present invention has been described with respect to 
particular embodiments, those skilled in the art will recognize that the present 
25 invention is not limited to these specific exemplary embodiments. Different formats, 
embodiments, and adaptations besides those shown and described as well as many 
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variations, modifications, and equivalent arrangements may also be used to 
implement the invention. Therefore, while the present invention has been described 
in relation to its preferred embodiments, it is to be understood that this disclosure is 
only illustrative and exemplary of the present invention. Accordingly, it is intended 
that the invention be limited only by the scope of the claims appended hereto. 



